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INTRODUCTION 


For the purposes of this paper, program refers to a collection of activities or projects which 
must be performed according to a plan or schedule. The Space Exploration Initiative within 
the National Aeronautics and Space Administration (NASA) is an example. 

Dimensionality refers to both the various perspectives of a program and to the components 
within that perspective. It is, thus, appropriate to think of dimensions of dimensionality. 
For example, one dimension or perspective of a program is the projects which perform the 
program. Within the project dimension, the individual projects are the components of that 
dimensionality. The number of projects defines the spatial dimensionality of the project 
dimension. Thus, each perspective or dimension has a dimensionality of its own. The 
structure and associated values of all the various perspectives of a program define the 
program. 

A project refers to the collection of activities required to conceive, sell, design, develop, 
evaluate, produce, operate, support, evolve, and retire a given system. A project thus 
effects the life cycle of given system. A project is, thus, the system to conceive, sell, 
design, develop, evaluate, produce, operate, support, evolve, and retire a system. 

A program, thus, effects the life cycle of the collection of projects required to effect the 
collection of systems required to implement the program. 

QUALITY FUNCTION DEPLOYMENT AND EXTENSIONS 

In their desire to design quality into a product, the Japanese have developed a process 
labeled Quality Function Deployment (QFD) (King (1989)). QFD utilizes basic 
dimensionality within a program to provide a structured way of ensuring that quality is 
designed into a system. It addresses the dimensions of customer desire, quality 
characteristics, functions, parts, and failure modes. 
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A customer desire is the quality demanded by the customer. A quality characteristic is a 
measurable attribute by which one can measure if a customer is attaining the demanded 
quality. A function is something the system must do which assists in meeting the 
demanded quality. Following Gause and Weinberg (1989), a function shall be of the form 
<verb,noun>. Quality characteristics and functions intersect, as shown in Figure 1, to 
define requirement variables of the form <function,attribute> which can be equated to a 
constant to define a requirement in the sense of Gause and Weinberg (1989). Note that all 
requirement variables do not have to be fixed to establish a requirement. They can also be 
treated as variables which can used as design guidelines for improving the program. 
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Figure 1 : Requirement Definition 

In QFD, each customer desire is given a value. Quality characteristics are defined through 
brainstorming to generate an affinity diagram. After forming a tree diagram of the chosen 
quality characteristics, the lowest level quality characteristics are placed on the axis of a 
matrix. The customer desires are placed on the other axis of the matrix. Each quality 
characteristic is compared with each customer desire to determine if there is no correlation 
(value = 0), a weak correlation (value = 1), a moderate correlation (value = 3), or a strong 
correlation (value = 5 (Japan) or 9 (America). The dot product of the customer desire 
values and the correlations for a specific quality characteristic provide a value for that 
quality characteristic. This may be interpreted as the relative value of a quality characteristic 
for a specific customer desire valuation. Mathematically speaking, the vector of values of 
customer desire are transformed to vector of values for quality characteristics through the 
customer desire/quality characteristic correlation matrix. The same process is used to 
identify functions, correlate them with customer desires, and transform customer desire 
values to function values through the customer desire/function correlation matrix. 

At this point, quality characteristics and functions can be ranked in terms of transformed 
customer value to determine which are the most important. This is sometimes used for task 
prioritization. If resources are constrained, then most priority should be given to quality 
characteristics and functions with the highest customer value. Also, it is sometimes used to 
establish initial cost targets, as a percentage of an overall cost target, for attaining quality 
characteristics and implementing functions. 
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Since QFD was developed to design quality into small systems such as car doors and rear 
view mirrors, QFD has historically not been applied to large systems. It thus requires 
tailoring for application to large systems (Dean and Unal (1992). For example, the concept 
of parts must be extended to systems. It also becomes more expedient to view QFD in the 
perspective of defining a system which must meet demanded quality, a subtle but important 
distinction. This leads to the definition of functions prior to the definition of quality 
characteristics and to the definition of quality characteristics in relation to the 
accomplishment of functions. 

Going beyond QFD, the product of the function value, the quality characteristic value , and 
the function/quality characteristic correlation value can be used to rank requirement 
variables. This ranking can be used to provide both prioritization and cost targets for the 
requirements. 



Figure 2: Allocating Requirements to Subsystems 

In keeping with the American system engineering process (Blanchard and Fabrycky 
(1981)), functions are allocated to systems as in Figure 2. That is, a given system 
performs a given set of functions. This can also be viewed as the allocation of 
requirements to systems in that a given system must meet a given set of requirements. 

Note that each requirement variable is a measurable attribute for the functions in which a 
correlation exists between the function and the quality characteristic. It is thus on the Akao 
A2 plane that measurable quantities exist. If these variables can be related through 
equations, then they provide a parametric behavioral description of the program. 

As illustrated by Figure 3, customer desire values can also be transformed to new concept 
values through the customer desire/new concept correlation matrix and to failure mode 
values through the customer desire/failure mode correlation matrix. Concept trades can be 
performed as illustrated by Figure 4. Concepts become requirement/subsystem planes over 
which cost, schedule and performance are evaluated. The evaluation may provide feedback 
for further requirements which may modify subsystems. 
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Figure 3: New Concepts and Failure Modes 




CONCURRENT ENGINEERING 


For large systems, expertise across many fields is required to define and rank the customer 
demands, functions, quality characteristics, systems, new concepts, failure modes, and 
associated correlation matrices. Thus, the need for concurrent engineering emerges. 
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As defined by Winner, Pennel, Bertrand, and Slusarczuk (1988), 

Concurrent engineering is a systematic approach to the integrated, 
concurrent design of products and their related processes, including 
manufacture and support. This approach is intended to cause the 
developers, from the outset, to consider all elements of the product life cycle 
from conception through disposal, including quality, cost, schedule, and 
user requirements. 

Figure 5 illustrates dimensionality associated with this definition. The life cycle or project 
functions are staffed with the appropriate disciplines over time to operate on the phases of 
the project for each system. For example, the conceptual design of the operations phase 
roughly defines the operations concept; the design of the operations phase finalizes the 
operations concept; the development of the operations phase provides a prototype 
operations system for test and evaluation; the test and evaluation function evaluates the 
prototype operations system; the production of the operations phase provides the final 
operations system; the operation of the operations system is the actual operating of the 
system; the support of the operations phase includes the maintenance and supply of the 
operations system; and the retirement of the operations system terminates all operations 
activities and disposes of the operations system. 



When continuous improvement is considered, concurrent engineering needs to consider all 
aspects and all phases of the system throughout the life cycle of the system. These aspects 
include designing for assembly, availability, cost, customer satisfaction, disposability, 
electronic compatibility, evolvability, maintainability, manageability, manufacturability, 
operability, performance, quality, recyclability, risk, safety, schedule, social acceptability, 
supportability, and all other attributes of the product. 



- 6 - 

Dean 


COST 

Note that the activities associated with each life cycle (project) function are the source of the 
cost of the system. This leads to a natural cost estimating structure illustrated by Figure 6. 
Figure 6 is a simple remapping of Figure 5 to include deliverables as well as labor. Note, 
also, the inclusion of parametric data as a part of the structure to be used for the generation 
of parametric cost estimating equations for the future. Note, also, that there is no set 
categorization for the cost categories. That may be mapped to the categories each 
organization estimates. 

Figure 7 is another projection of the structure to permit viewing cost in a more traditional 
sense. This figure intersects the more recent concept of activity based costing (Webster 
(1991)), the cost of the activities of the project functions, with the MI L STD 881 type of 
end item oriented work breakdown structure of subsystems. Each cell of the 
function/subsystem matrix contains the cost of a given function as performed by a given 
subsystem. Given cost in this form, an accurate representation of the cost of each 
subsystem and of each function is available. 

Note that the allocation variables in activity based costing are parameters which are used to 
allocate cost. They can also be used to estimate cost. They are a subset of the parametric 
data structure along with typical parameters such as weight and complexity. 



Figure 6: Life Cycle Cost Estimating Structure 
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Figure 7: Activity Based Cost Allocated To Subsystems 

CONCLUSIONS 

Although this paper has addressed only a small portion of the dimensionality of a program, 
it has applied QFD and extensions of QFD to the multidimensional definition of a program; 
and it has used the matrix concepts of QFD to explore the dimensionality of concurrent 
engineering and the cost of a program. Finally, this paper has demonstrated the power of 
dimensionality to analyze and integrate a program in a quantitative and structured manner. 
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